Subject: Support of Frame-Relay RFC1490 SNA Encapsulation

From: "jim (j.) cobban" <[email-masked]>
Date: Tue, 20 Jun 1995 16:26:00 -0400

One purpose of industry bodies such as the AIW and the Frame-Relay Forum is
to agree on critical aspects for interoperability.  With regards to the
encapsulation of SNA over Frame-Relay IBM has presented to the
Frame-Relay Forum and the AIW a recommendation written by Rao Cherukuri.
This recommendation is certainly not intended to be an exhaustive list of
the possible encapsulations for SNA, but it was obviously intended as a
minimum common middle ground which all vendors can agree on.  This
encapsulation was referenced explicitly in the HPR reference.

A problem which a number of people have commented on in this regard is the
lack of product support for this proposal.  This may reflect fundamental
inadequacies in the recommendation.  That is products are not implementing
this recommendation because it does not satisfy the needs of real
customers.  In particular there are existing products which transport SNA
using the 802.5 bridging format, for example BAN or RXR/2.  There are other
products which transport SNA by first encapsulating it inside TCP/IP, for
example the 6611.

We are not exactly overjoyed at the prospect of having to implement and
validate three different encapsulations of SNA just in order to be certain
of being able to communicate with all of the products out there. 

Should the AIW consider abandoning the existing recommendation and focussing
on the more flexible 802.5 ("bigGER, not BIG") and IP encapsulations?  Or
should we be more insistent that the recommended format is base
functionality, and therefore products which use another format exclusively
are not compliant to the architecture?

Jim Cobban   |  [email-masked]                        |  Phone: (613) 763-8013
BNR Ltd.     |  bnrgate.bnr.ca!bcars153!jcobban       |  FAX:   (613) 763-5199
|                                                                             |
|   The opinions expressed are those of the author and do not necessarily     |
|   represent the opinions of Bell-Northern Research or Northern Telecom.     |

---

From: "Bill Kwan" <[email-masked]>
Date: Wed, 21 Jun 1995 12:33:00 EST5EDT

> Date:          Tue, 20 Jun 1995 19:22:39 -0400
> Reply-to:      [email-masked]
> From:          "jim (j.) cobban" <[email-masked]>
> To:            [email-masked]
> Subject:       Support of Frame-Relay RFC1490 SNA Encapsulation 

> customers. 

Unless I misunderstood you, there are many products that have 
implemented the FRF.3 SNA encapsulation (written by Rao). For 
example, I definitely know the two companies that I have been recently
associated with  (CrossComm and Jupiter)  support it.  In fact, all of the
vendors that claim to be able to directly connect to  NCP 7.1 must be able to
do it (since that is the only format that version of NCP supported).  Many 
of the vendors also support bridging (both the format and the protocol). 
However,  I am not aware of many who currently support BAN (except for
IBM and Proteon). Although it would be pretty easy to implement BAN 
for those vendors that have already support bridging, I don't see a 
real good compelling reason for them to do so.  Before BAN, they 
could already interoperate with each other with the other techniques.

> In particular there are existing products which transport SNA
Me neither!
 
> are not compliant to the architecture?

I am not sure. My feeling is that BAN would have been a good idea if it came
out earlier. But it may be too late now. There are too many vendors that have 
already supported FRF.3.  Endorsing BAN exclusively at this time 
might create problems.  I am interested in what other people think.

> |   represent the opinions of Bell-Northern Research or Northern Telecom.     |

Regards,
Bill

Bill Kwan
Jupiter Technology, Inc.                                                                      
[email-masked]